If notification publishing/auditing fails, the status update has already been persisted but the handler returns 500; a client retry with the same X-Correlation-ID will hit the idempotency short-circuit and never re-attempt the notification, so the confirmed notification can be dropped permanently. Decouple status persistence from notification side-effects (e.g., outbox/audit written transactionally with the status update and processed asynchronously) or ensure the duplicate-correlationId path still triggers notification retry when no successful (QUEUED/SENT) audit exists.

SQS publish happens before inserting the QUEUED audit row, so if the DB insert fails after a successful send you can end up re-sending the same notification on retry (latest audit is FAILED/absent but the message is already on the queue). To make this idempotent, persist an audit/outbox record before publishing (or in the same DB transaction as the status update), and update/append status after publish so retries can safely detect that a message was already sent/queued.

getLatestAuditByCorrelationIdAndEventCode queries by (correlation_id, event_code) and orders by created_at, but the notification_audit table migration only indexes (message_reference, created_at); without a supporting index this lookup will degrade as the audit table grows. Add a DB index aligned to this access pattern (e.g., on (correlation_id, event_code, created_at DESC) or similar) to keep the dedupe check efficient.

Failures from sqsClient.sendMessage() / notificationAuditDbClient.insertNotificationAuditEntry() are caught later in this method and only logged, so the handler will still return 201 even when the notification was not queued/audited and no retry is triggered. Consider rethrowing after logging (or writing an outbox/failure record for async retry) to avoid silently dropping notifications.

buildOrderStatusNotifyMessage accepts both patientId? and recipient?, but the implementation requires at least one and otherwise throws at runtime; model this constraint in the type (e.g., a union of { patientId: string; recipient?: never } | { recipient: NotifyRecipient; patientId?: never }) so invalid internal calls are caught at compile time.